アジャイルの概要（1章 アジャイル入門）
ソフトウェアプロジェクトの管理（マネジメント）
鉄十字＝プロジェクトマネジメントのトレードオフ
4つ全部を100%にはできない
データを提供する
週の平均ベロシティ
バーンダウンチャート
この2つからマイルストーンに到達可能な時期が（誰でも）わかる
アジャイル開発とは、「フィードバック駆動のアプローチ」
2つは「壁のチャート」となることが多い
最初に知るべきこと＝納期
ビジネス上の理由があり、動かせない（凍結された）
要求は凍結できない。流動的
ウォーターフォールの例
分析（2ヶ月） -> 設計（2ヶ月） -> 実装（2ヶ月）
なぜ分析が完了したのか？それは7月1日だからだ。スケジュールでは、この日に分析が完了する予定になっている。だから、7月1日に分析が完了した。遅れるはずがないだろう？（皮肉）
分析や設計には明確な完了基準がない（完了したふりができる）
そしてデスマーチへ（この例ではさらに4ヶ月追加されている）
実装には完了基準がある（なので、終わらない！となる）
実装中も要求は変わる
（感想：凍結できない要求を凍結して扱っている印象）
アジャイルの例
アジャイルとは、プロジェクトをイテレーションに分割するプロセスだ。
各イテレーションのアウトプットを計測して、スケジュールを継続的に評価する。
最も価値のあるものが最初に実装されるように、ビジネス価値の順番で機能を実装していく。
クオリティは可能な限り高める。
スケジュールはスコープの調整によって管理する。(Kindle の位置No.720-723 「これにてアジャイルの概要は終わり」より)
アジャイルなプロジェクトとは
分析も設計も実装も常にやる（順番ではない）
イテレーションゼロ
ストーリー
初期計画（暫定的）
「アジャイルが生成するデータ」
実際のデータによるフィードバック
アジャイルのゴールは、希望の喪失
希望がプロジェクトを殺す
うまくいっていないことを早期に知りたい（そのためのデータ）
可能な限り最高の成果
鉄十字のマネジメント
＝スコープの調整
スコープの調整ばかりでいいのか？ 👉 そのプランニングに意思、乗せていますか？